perm filename MOORE1.TO[P,JRA]1 blob sn#147637 filedate 1975-02-21 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	hi:
C00007 ENDMK
C⊗;
hi:
this message is  kind of long......

things are getting farther and farther behind, but here at least
is an outline of proposed modifications.

1. much heavier emphasis on abstraction.
   more said about its benefits in introduction
   bit more when s-exprs are introduced
   section introducing lists uses "seq" instead of list
    since as a abstract data structure, that's what we are
    talking about. Motivated by noting relation with (a)conventional
    languages- vectors and arrays (b) just as a mathematically interesting
    structure, which we claim will be of use later. Nothing is said
    about representation. "sequence" manipulating functions are
    written lisp-style ( i.e. control structures are recursion-call-by-value
    and conditional); similar to current but cleaner. (concat is a bad name)
    Then we map to a representation as sexprs, introducing the represntatio
    problem. Curent notes do this but not very neat. At this point we talk
    about abstraction in more detail; show  problems of mapping INTO
    rather than ONTO. 

 again in the differentiation example bit more about beneficial aspects
  of final version of diff in terms of const-sel-recog.(and i/o)

 the "value" example is completely revised. we START abstractly, since
the point is already made in diff that that is the proper way to  program.
various versions of polynomial evalution are done.

1. constants + and *
2. 1. plus variables: evlaute x+y when x=2 and y=3
3. now add: evaluate f[2;3] when f[x;y] <= x+y

you  can see what i'm doingg. each level adds a bit more mechanism.
2→ symbol tables; 3→ ad-hoc λ-calc. This is currently done
in chapter on evaluation in the context of LISP. The reason for
changing is that the studetn can relate his intuition to polys.
better than to lisp evaluation; there is only one new thing happening
rather than two. Obviously the stuff in the evaluation chapter is diminished
accordingly.  The symbol table stuff and λ-cal stuff and indeed the
polys themselves are all done abstractly. this can be justified by the
discussion of I/O conventions introduced in the seq-list representation
section; we will come back to the parser/unparser problems by using SDIO
later. thus symbol tables look like:
(<x:2>, <x:3>, <f: [[x;y] x+y]>) rather than usual dotted-pair  stuff.
(cambridge polish  example also is used to keep our feet on the ground)
(page 9 lect.sju [lsp,jra] has a complete abstract value)

randon other changes:
discussion of waht is a data structure: const-sel-rec isn't sufficient
dsicussion of waht is prog lang: data struct, control struct and operations.
consistent use of  first, rest and concat(new name) for sequence operation.
more on what is good programming style and way to write good lisp.

there's more, but running out of time. If you want to respond, please
do. It will be a while before I get all mods in. If you want to
get a feel for what going on at san jose course, look at lect.sju[lsp,jra](2:9)
its pretty cryptic but..  I'd really like to get together and talk
sometime soon but things have really been hectic.